home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re List manager.1 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.1 KB  |  [TEXT/ttxt]
  1. Subject:     Re: List manager
  2. Sent:        5/15/96 12:58 PM
  3. Received:    5/17/96 9:03 AM
  4. From:        Mark Lanett, mlanett@meer.net
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 8:15 AM 5/15/96, Bruce Alspaugh wrote:
  9. >        There are several limitations with using the Mac List Manager that
  10. >I see...I would
  11. >strongly suggest not using the List Manager because of its limitations.
  12.  
  13. Well, for as many people who need flexible tables, there are just as many
  14. who only need simple text lists. While a hand-written table class may be a
  15. functional superset of the Mac list manager, those who only need the
  16. standard functionality may find it to be harder to use (different and new
  17. API), adds to code bloat, and, since it is not a platform control, doesn't
  18. benefit from system updates (the Mac list manager may be worthless now and
  19. forever but what if the Windows list manager provides features like
  20. type-selection, and a consistent UI). Also a hand-written table, since it
  21. is duplicating functionality, will also duplicate bugs that are already
  22. worked out of the platform-specific control. We don't want to get into the
  23. business of re-implementing (and debugging and maintaining) things which
  24. are already provided by all operating systems.
  25.  
  26. So we have a dichotomy: platform controls are more desirable in general,
  27. but may be too limited in some cases (i.e. Mac). In ODF's case, we chose to
  28. provide a platform-based list manager initially, and, probably, a
  29. platform-independent one in the future, if it is required. However there
  30. hasn't been time to complete one thus far. Hopefully the platform list
  31. manager should suffice for most people at least for the short term.
  32.  
  33. PowerPlant takes one approach: it offers both as separate classes. ODF may
  34. do that, or may offer a single interface which uses a platform control for
  35. one platform, but implements it using C++ for another. Given that Windows
  36. OD isn't here yet, it's probably better to play it safe and stick to
  37. platform controls unless they *clearly* don't satisfy even your 80% needs.
  38.  
  39.  
  40. Mark Lanett, ODF
  41.  
  42.